home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 4643 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB
  1. Path: peer-news.britain.eu.net!uknet!str-ccsun!not-for-mail
  2. From: nbc@vulture.dmem.strath.ac.uk (Neil Brendan Clark)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Acorn RiscPC --- a thought?
  5. Date: 8 Feb 1996 18:50:30 -0000
  6. Organization: University of Strathclyde
  7. Message-ID: <4fdglm$b8s@vulture.dmem.strath.ac.uk>
  8. References: <1996Feb5.164323.465@rmcs.cranfield.ac.uk> <4f5qvt$1hm@vulture.dmem.strath.ac.uk> <1996Feb8.124744.14853@leeds.ac.uk>
  9. NNTP-Posting-Host: vulture.dmem.strath.ac.uk
  10.  
  11. J M Oldak <csxjmo@scs.leeds.ac.uk> wrote:
  12. >Neil Brendan Clark writes:
  13. >
  14. >There is nothing wrong with cooperative multitasking, when implemented
  15. >properly. 
  16.  
  17. You are wrong. With cooperative multitasking, the current program will soak
  18. up all the CPU time it can get until it voluntarily relinquishes the CPU,
  19. either explicitly with a "yield()" type call or by calling certain system
  20. functions. This has several implications; a runaway task can hog the entire
  21. computer, requiring a reboot. It is more difficult to program well, as 
  22. you have to explicitly decide when to give up the CPU. Busy tasks have
  23. a hard time of it too; imagine you decide to, say yield every 1000 iterations
  24. of some loop. On a slow machine, this may be fine in terms of user response,
  25. but on a faster machine, you'll be wasting CPU time by yielding too often.
  26. So the programmer sets up timing mechanisms to help? Fine. More CPU time,
  27. more hassle, more bugs. Any notion of the system of being remotely real-time
  28. is effectively quashed.
  29.  
  30. >whereas Risc OS (Acorn's operating system) allowes all
  31. >tasks to have processor time. 
  32.  
  33. How does it do this? Does it force a task off the CPU at certain time 
  34. intervals?
  35.  
  36. >This means I can run a DTP program, 
  37.  
  38. Shouldn't need any CPU unless it is being used at the time...
  39.  
  40. >command shell, 
  41.  
  42. See above.
  43.  
  44. >desktop utilities, 
  45.  
  46. See above.
  47.  
  48. >be printing in the background, 
  49.  
  50. And quite rightly too! This is not difficult, as printing generally involves
  51. little CPU time, unless you are interpreting PostScript with the CPU. The
  52. printer goes much slower than the CPU after all. OK, you have this one.
  53.  
  54. >viewing JPEG's (as part of the OS - without de-compressing) 
  55.  
  56. Accuse me of pushing technicalities here, but the JPEG still needs to be
  57. decrompressed, albeit by hardware(?). A cool thing, for sure, but ultimately
  58. how useful? My P75 running FreeBSD decompresses a 640x512 JPEG in 0.8 seconds.
  59.  
  60. >without things grinding 
  61.  
  62. Why should things grind when there are only two tasks desiring CPU use at
  63. one time, one of which is a printer spooler?
  64.  
  65. >(and all in 24 bit colour....)
  66.  
  67. Yes, this is good. I *did* say they were nice machines though ;-)
  68.  
  69. >Admittedly - the OS has lacked development recently, but there is a new version
  70. >coming out soon, 
  71.  
  72. Hopefully with proper multitasking. I think part of the problem with people
  73. who claim that you don't need pre-emptive MT is that they have never really
  74. used it before. Once you have used such a system, there is no going back. 
  75.  
  76. >together with new processor cards which should deliver up to
  77. >260 MIPS. That's faster than the fastest PC (and the fastest Amiga)...
  78.  
  79. Is this the StrongARM chip? If so, then that is very good. Get a decent OS
  80. and you should be flying. NetBSD + StrongARM would be a formidable combination.
  81.  
  82. -- 
  83. "I have trouble imagining death at that income level" - White Noise, D.Delillo
  84.  
  85.                  Neil Clark, Transparent Telepresence Group
  86.                    http://telepresence.dmem.strath.ac.uk
  87.